可能会|租户_Volcano成Spark默认batch调度器

篇首语：本文由编程笔记#小编为大家整理，主要介绍了Volcano成Spark默认batch调度器相关的知识，希望对你有一定的参考价值。

摘要&＃xff1a;对于Spark用户而言&＃xff0c;借助Volcano提供的批量调度、细粒度资源管理等功能&＃xff0c;可以更便捷的从Hadoop迁移到Kubernetes&＃xff0c;同时大幅提升大规模数据分析业务的性能。

2022年6月16日&＃xff0c;Apache Spark 3.3版本正式发布&＃xff0c;其中《Support Customized Kubernetes Schedulers》作为Spark 3.3版本的重点&＃xff08;Highlight&＃xff09;特性&＃xff0c;其关键能力是从框架层面支持定制化的Kubernetes度器&＃xff0c;并且将Volcano作为Spark on Kubernetes的默认batch调度器。这也是Apache Spark社区官方支持Volcano的第一个版本。对于Spark用户而言&＃xff0c;借助Volcano提供的批量调度、细粒度资源管理等功能&＃xff0c;可以更便捷的从Hadoop迁移到Kubernetes&＃xff0c;同时大幅提升大规模数据分析业务的性能。

华为牵头发起&＃xff0c;主流厂商协作

该特性由华为牵头发起&＃xff0c;由来自华为、Apple、Cloudera、Netflix、Databricks等公司的开发者共同协作完成。通过在Apache Spark支持自定义调度能力&＃xff0c;允许用户插件化使用各种第三方自定义调度。

Spark &＃43; Volcano&＃xff1a;更完善的调度能力

Spark的资源管理平台正在向Kubernetes演进&＃xff0c;Apache Spark现有架构下&＃xff0c;Job的单主、多从节点的分离调度&＃xff0c;导致了Spark driver节点资源死锁问题&＃xff0c;尤其是在资源紧张的情况下&＃xff0c;会经常出现此类问题。同时&＃xff0c;由于原生Kubernetes的调度能力受限&＃xff0c;也无法完成Job粒度诸如队列调度、公平调度、资源预留等功能。

Volcano作为CNCF社区首个云原生批量计算&＃xff0c;于2019年6月在上海KubeCon正式开源&＃xff0c;并在2020年4月成为CNCF官方项目。2022年4月&＃xff0c;Volcano正式晋级为CNCF孵化项目。Volcano社区开源以来&＃xff0c;在人工智能、大数据、基因测序、转码、渲染等海量数据计算和分析场景得到快速应用&＃xff0c;并构建起完善的上下游生态&＃xff0c;目前腾讯、爱奇艺、小红书、蘑菇街、唯品会、鹏程实验室、锐天投资等企业均将Volcano应用于生产环境。

Spark 官方支持Volcano将会进一步加速大数据平台迁移到Kubernetes的进程&＃xff0c;帮助Spark用户应对以下常见的批量调度场景。

常见调度场景&＃xff1a;

作业级的公平调度 (Job-based Fair-share)

当运行多个弹性作业&＃xff08;如流媒体分析&＃xff09;时&＃xff0c;需要公平地为每个作业分配资源&＃xff0c;以满足多个作业竞争附加资源时的SLA/QoS要求。在最坏的情况下&＃xff0c;单个作业可能会启动大量的pod资源利用率低&＃xff0c;从而阻止其他作业由于资源不足而无法运行。为了避免分配过小&＃xff08;例如&＃xff0c;为每个作业启动一个Pod&＃xff09;&＃xff0c;Volcano允许弹性作业定义应该启动的Pod的最小可用数量。 超过指定的最小可用量的任何pod都将公平地与其他作业共享集群资源。

队列 (Queue)

队列还广泛用于共享弹性工作负载和批处理工作负载的资源。队列的主要目的是&＃xff1a;

• 在不同的“租户”或资源池之间共享资源&＃xff0c;例如将每一个部门映射到一个队列&＃xff0c;实现多个部门通过队列的权重&＃xff0c;动态共享集群的资源。
• 为不同的“租户”或资源池支持不同的调度策略或算法&＃xff0c;如FIFO、Fairness、Priority等

队列被实现为集群范围的CRD&＃xff0c;和namespace实现了解耦。这允许将在不同namespace中创建的作业放置在一个共享队列中。队列还提供了min和max&＃xff0c;min是队列的最小保障资源&＃xff0c;任何时刻该队列有紧急任务提上来都保证有min资源可用&＃xff0c;max是队列资源使用上限。min和max之间的资源如果闲置&＃xff0c;允许共享给其他队列的任务来提升整体的资源利用率。

面向用户的, 跨队列的公平调度 (Namespace-based fair-share Cross Queue)

在队列中&＃xff0c;每个作业在调度循环期间有几乎相等的调度机会&＃xff0c;这意味着拥有更多作业的用户有更大的机会安排他们的作业&＃xff0c;这对其他用户不公平。 例如&＃xff0c;有一个队列包含少量资源&＃xff0c;有10个pod属于UserA&＃xff0c;1000个pod属于UserB。在这种情况下&＃xff0c;UserA的pod被绑定到节点的概率较小。

为了平衡同一队列中用户之间的资源使用&＃xff0c;需要更细粒度的策略。考虑到Kubernetes中的多用户模型&＃xff0c;使用名称空间来区分不同的用户&＃xff0c; 每个命名空间都将配置一个权重&＃xff0c;作为控制其资源使用优先级的手段。

抢占 (Preemption & Reclaim)

通过公平分享来支持借贷模型&＃xff0c;一些作业/队列在空闲时会过度使用资源。但是&＃xff0c;如果有任何进一步的资源请求&＃xff0c;资源“所有者”将“收回”。 资源可以在队列或作业之间共享&＃xff1a;回收用于队列之间的资源平衡&＃xff0c;抢占用于作业之间的资源平衡。

最小资源预留&＃xff08;minimal resource reservation&＃xff09;

运行拥有多个任务角色的作业时&＃xff08;如Spark&＃xff09;时&＃xff0c;Spark driver pod会先创建并运行&＃xff0c;然后请求Kube-apiserver创建Spark executor pod&＃xff0c;在资源紧张或高并发的场景&＃xff0c;时常会出现大量作业提交导致所有可用资源被Spark driver pod耗尽&＃xff0c;Spark executor无法获取资源&＃xff0c;最终所有Spark作业无法正常运行。为解决此问题&＃xff0c;用户为Spark driver pod 和 executor pod创建专有节点进行静态划分&＃xff0c;而这带来了资源碎片、利用率低下的问题。Volcano提供的minimal resource reservation 允许为每个Spark作业预留资源&＃xff0c;防止Spark executor无法获取资源而导致的死锁问题&＃xff0c;相比于静态划分的作法&＃xff0c;性能提升30%&＃43;。

预留与回填 (Reservation & Backfill)

当一个请求大量资源的“巨大”作业提交给Kubernetes时&＃xff0c;当有许多小作业在管道中时&＃xff0c;该作业可能会饿死&＃xff0c;并最终根据当前的调度策略/算法被杀死。为了避免饥饿&＃xff0c; 应该有条件地为作业保留资源&＃xff0c;例如超时。当资源被保留时&＃xff0c;它们可能会处于空闲和未使用状态。为了提高资源利用率&＃xff0c;调度程序将有条件地将“较小”作业回填到那些保留资源中。 保留和回填都是根据插件的反馈触发的&＃xff1a;Volcano供了几个回调接口&＃xff0c;供开发人员或用户决定哪些作业应该被填充或保留。

未来发展

随着场景的日益丰富&＃xff0c;Volcano也在不断的添加新的算法&＃xff0c;同时&＃xff0c;相应的接口也在不断的完善&＃xff0c;方便用户扩展并自定义相应的算法。另一方面&＃xff0c;社区也在持续的扩大技术版图支持新的场景如跨云跨集群调度、混部、FinOps、智能弹性调度、细粒度资源管理等。

近期我们还会对Spark 3.3中Volcano 带来的批量调度能力进行详细技术解读&＃xff0c;敬请期待。添加Volcano小助手k8s2222&＃xff0c;进入Volcano社区交流群&＃xff0c;大咖在侧&＃xff0c;定期分享。

Spark 3.3 release notes: https://spark.apache.org/releases/spark-release-3-3-0.html

Volcano官网&＃xff1a;https://volcano.sh/zh/docs/

Github : https://github.com/volcano-sh/volcano

点击关注&＃xff0c;第一时间了解华为云新鲜技术~